Análisis de costes

En este documento vamos a encontrar feedback respecto a los costes asociados a nuestro proyecto.

Semana 1

El Presupuesto Temporal consiste en 150 horas de trabajo por cada miembro del grupo.
Asegurarse de tener un plan claro y realista en términos de tiempo.
Considerar la viabilidad de las metas dentro del plazo establecido.
Coste Total de Propiedad (TCO): Consiste en cúanto cuesta mantener la aplicación activa al mes. Es super importante.
Es necesario realizar un análisis de coste preeliminar. Esto está contemplado en una pildora teorica.

Separar en el análisis de costes el TCO (coste total de propiedad) del proyecto del coste de mantenimiento.
No se debe expresar los costes (TCO) de manera anual, los costes de los servicios se deben poner de forma mensual.
Considerar la inclusión de una tabla con los costes mensuales estimados.
Detallar los costes específicos, como herramientas, licencias y otros gastos asociados.
Proporcionar evidencia del seguimiento del presupuesto.

Siguen sin quedar claro los gastos relacionados con GitHub, en concreto los gastos que se asumen como estudante, en una empresa esos gastos son reales.
Hacer incapien entre diferencia entre coste de desarrollo y el coste de mantenimiento asi como cuanto debe pagar el cliente.
No expresar el ROI con decimales, es mas comodo para el público.
Estimación del TCO como título.

Cuanto mayores son los números en cuanto a ROI mayor debe ser el Elevator Pitch, orientado a estos números. Si son poco realistas deben ser repensados.
No confundir coste de mantenimiento con coste de operación, el mantenimiento puede ser por ejemplo el correctivo (para posibles fallos) o aumentativo (hay suficiente dinero como para hacer añadidos).
Para el TCO es pertinente definir un marco de tiempo (time frame) y una capacidad de demanda nominal para comprender mejor cómo se comportará el sistema en diferentes condiciones de uso, en resumen, cómo escalará. No solo se trata de cuántos usuarios pueden usarlo al mismo tiempo, sino también de cuándo y con qué nivel de demanda.
Hablar de porcentajes del número de usuarios que tienen que usar nuestra aplicación (TCO) con respecto al número de usuarios potenciales.
El número de usuarios que necesitamos para mantener la aplicación debe tener porcentajes con respecto al número de personas en el sector en Sevilla por ejemplo.

Para la semana del 19/03/2024 se ha pedido un resumen del TCO (añadiendo el actions), indicar la situación actual respecto actual y añadir las estimaciones realistas, pesimistas y optimistas.
Para las estimaciones se ha pedido un porcentaje sobre el total de usuarios, e indicar de dónde salen los numeros estimados y totales.
También se ha pedido que cuando insertemos gráficas, no pueden ser lineales, puesto que no siempre vamos a tener la misma cantidad de usuarios.

Justificar siempre por qué se darían datos optimistas o pesimistas.
Los números realistas deben ser lo suficientemente optimistas como para que sea rentable como para que un equipo pueda mantenerla. Luego estos números se podrán justificar en la campaña de lanzamiento durante los próximos sprints.
ingreso y beneficio no es lo mismo. Ingreso es el dinero que se ingresa y beneficio cuando el dinero supera a los costes.
Indicar el salario bruto por hora.

Explicar los escenarios pesimista, optimista y realista sacando datos de usuarios de fuente reales y contrastadas (periódicos, medios deportivos, portales del gobierno…), si es posible, es buena practica.